SD-2190 BUG: Import fails when a list of figures/tables is the first node in the document

Status: FAIL

One spec violation in the export path, plus a minor default value issue.

1. translate-document-part-obj.js — inline SDT containing block content

The new wrapDocumentPartInParagraph function produces:

<w:p w:rsidRDefault="...">
  <w:pPr>...</w:pPr>
  <w:sdt>
    <w:sdtContent>
      <w:p>...</w:p>   <!-- paragraph child! -->
    </w:sdtContent>
  </w:sdt>
</w:p>

Per §17.5.2.31, a w:sdt inside a w:p is an inline-level SDT (CT_SdtRun) whose sdtContent must hold run-level content. A w:docPartObj SDT is explicitly defined (§17.5.2.13) as a block-level construct for tagging "a set of block-level objects." Nesting it inside w:p violates both CT_SdtRun's content model and docPartObj's semantics. See https://ooxml.dev/spec?q=sdtContent+inline+block and https://ooxml.dev/spec?q=docPartObj.

This is clearly intentional — the PR is round-tripping documents that already had this unusual structure — but the export output is technically non-conformant OOXML. If Word generated the original file, it probably placed the docPartObj SDT at body level. The safer export would be to emit the block SDT at body level (with the paragraph attributes forwarded as a preceding w:p if needed) rather than re-creating the malformed wrapping.

2. document-part-object.js — docPartUnique default

docPartUnique: {
  default: true,   // pre-existing, not introduced here
},

This is pre-existing and not changed by this PR, but it interacts directly with the new wrapperParagraph machinery: any documentPartObject node created without an explicit docPartUnique: false will export <w:docPartUnique/>. Per §17.5.2.14, the element being absent is meaningful (the SDT is not a built-in document part container). Defaulting to true causes the exporter to assert built-in status on every SDT, including ones where the original <w:docPartUnique/> was absent. The default should be false or null. This PR doesn't introduce the problem but it does widen the surface where it matters since more nodes now go through this export path.

Everything else checks out — w:id/@w:val as ST_DecimalNumber (§17.5.2.18), w:docPartGallery/@w:val as ST_String (§17.5.2.11), w:docPartUnique as a toggle (§17.17.4 — present-with-no-val implies true), and w:keepNext/@w:val="true" are all handled correctly.

About the OOXML Spec Review failure above, the docx file that originated this PR has exactly the structure that the report is saying isn't valid but was created with Word:

<w:p w14:paraId="41964671" w14:textId="04598795" w:rsidR="00233D7B" w:rsidRPr="003104CE" w:rsidRDefault="00233D7B" w:rsidP="003104CE">
  <w:sdt>
    <w:sdtPr>
      <w:id w:val="123456789"/>
      <w:docPartObj>
        <w:docPartGallery w:val="Table of Figures"/>
        <w:docPartUnique/>
      </w:docPartObj>
    </w:sdtPr>
    <w:sdtContent>
      <w:p w14:paraId="11111111" w14:textId="11111111">
        <w:r>
          <w:t>Table of Figures</w:t>
        </w:r>
      </w:p>
      <w:p w14:paraId="22222222" w14:textId="22222222">
        <w:r>
          <w:t>Figure 1</w:t>
        </w:r>
        <w:r>
          <w:tab/>
        </w:r>
        <w:r>
          <w:t>1</w:t>
        </w:r>
      </w:p>
    </w:sdtContent>
  </w:sdt>
</w:p>

Therefore I don't think the analysis result is valid.

Status: PASS

The OOXML handling in this PR is spec-compliant. Here's what I checked:

w:docPartObj / w:docPartGallery / w:docPartUnique (§17.5.2.13–14): All three are used correctly. w:docPartGallery takes a string w:val, w:docPartUnique is treated as a presence-based boolean (element present → true), and both must be children of w:docPartObj inside w:sdtPr. The test fixtures match this structure exactly.

w:id on w:sdtPr (§17.5.2.18): Used with w:val="123456789" — a valid ST_DecimalNumber integer. ✓

w:keepNext serialization: The export test expects { name: 'w:keepNext', attributes: {} } (i.e., <w:keepNext/>). Per the common boolean property definition (§17.17.4), omitting w:val on a present element implies true. ✓

w:spacing attributes: w:after, w:line as integers and w:lineRule="auto" are all valid. ✓

Paragraph rsid attributes (w:rsidRDefault, w:rsidR, etc.) and w14:paraId / w14:textId: All valid w:p attributes. The identity-attribute partitioning (IDENTITY_ATTR_NAMES) correctly avoids duplicating paraId/textId across synthetic paragraph fragments, since each w:p must have a unique paraId per the Word 2010 namespace spec.

The wrapping behavior (wrapperParagraph): The round-trip produces <w:p><w:sdt w:docPartObj>...</w:sdt></w:p> — this is technically an inline-level SDT (§17.5.2.31) containing block content, which is non-standard. But this mirrors the structure of real-world documents being imported, not a new violation introduced by this PR. The code is faithfully preserving what was there.

No non-existent attributes, no incorrect defaults, and no new spec violations introduced. The wrapperParagraph: { default: null } addition is purely an internal PM attribute with no OOXML representation of its own.